The convergence of the mobile telephone network, the static telephone network, and the IP network provides a myriad of communication options for users. If one seeks to contact another individual, he or she may do so by electronic mail or e-mail, instant messaging (IM), wired or wireless telephone, personal computer, pager, personal digital assistant (PDA), and Unified Messaging (UM) systems, to name but a few. With so many options, it is difficult, if not impossible, to determine which option at a given point in time will provide the caller with the highest likelihood of contacting the desired individual or contact. Trial and error and guesswork are the typical techniques used to reach the contact, which more often than not leads to a waste of time and frustration on the part of the caller. The concept of unified communications (e.g., the integration of real-time communication services) is increasingly pervasive in corporate communication solutions where users want to find out whether certain contacts (or other users) are available to communicate. A user's availability to communicate is determined from the user's presence information. A contact's presence information is obtained by a watcher (e.g., a user subscribing to that contact) by means of a presence subscription. Further, a contact's availability to communicate is determined from that contact's published presence information. In some embodiments, a user may search for other users in an organization in an unified communications solution, and presence information is rendered along with the search results.
Thus, “presence” is a well known concept in the telecommunications industry. Presence relates to a communication state of a user or contact on a particular client or communication device. In other words, presence and presence information relate to a person having multiple devices with multiple communication paths and a contact's preference or preferred device of availability. “Presence information” typically refers to any information associated with a network node and/or endpoint device, such as a communications device, that is in turn typically associated with a person or entity. Various attempts have been made to provide a presence awareness network (also called a presence system), which would temporally track an individual's usage of selected communication devices to provide a user with the highest likelihood of contacting the individual. Examples of presence information include registration information under the Session Initiation Protocol (SIP) or Extensible Messaging and Presence Protocol (XMPP), information regarding the accessibility of the endpoint device, the endpoint(s) telephone number or address, the recency of use of the endpoint device by the person, recency of authentication by the person to a network component, and the preferences of the contact, such as contact mode preferences or profiles, such as the communication device to be contacted for specific types of contacts or under specific actual scenarios or presence contacts, contact time preferences, impermissible contact types and/or subjects, such as the subjects about which the person does not wish to be contacted, parties who must not be contacted, e.g., a do not call if you are not calling on behalf of a specific person or entity, and parties who can contact at any time, e.g., “I will accept a call from the head of the company regardless of what I am doing.” SIP and XMPP have been developed to provide a degree of presence awareness in a communication network. Although other protocols may be equally supportive of presence concepts, SIP and XMPP provide an illustrative basis for the present disclosure.
Current presence systems use presence subscriptions to provide an interested user with an indication as to a contact's availability to communicate. From the contact's side, contacts can publish their presence state (also called presence information) for various configured modes of communication to a presence server, where users can obtain the published presence information by subscribing to the contact's presence information. In a SIP protocol, a user can subscribe to a contact's presence information using a SUBSCRIBE request. In an XMPP protocol, a user can subscribe to a contact's presence information by submitting a presence subscribe packet. In both protocols, a user may subscribe to presence information for any one or more of the user's contacts. Once a presence subscription has been established and authorized, the subscribing user is then notified of any initial presence information and any presence information update for the contacts to which the user is subscribed. Such a notification is referred to as a “report” or “notification” herein. The subscription is established between the subscribing user (e.g., watcher), and the contact (also known as a “presentity”).
Although SIP, XMPP, and other presence systems provide some degree of presence awareness, there are problems with the existing schemes. One problem is that when a user submits a subscription request for multiple contacts' presence, individual presence subscriptions for each contact are generated by the presence server. Each presence subscription requires Access Control List (ACL) privacy policy processing and the creation of individual dialogues and/or individual subscription and notification requests. These individual presence subscriptions are costly in terms of central processing unit (CPU) usage and network bandwidth.
For example, in a SIP protocol, subscribing to multiple contacts' presence information creates individual SIP sessions including individual subscription requests (e.g., SUBSCRIBE requests) and corresponding individual notification requests (e.g., NOTIFY requests) for each contact. Also, SIP presence subscriptions are short-lived, and are terminated almost instantaneously when the search results are displayed. This creates a problem of increased processing requirements because users must request subscriptions multiple times to display updated subscription results. In the case of an XMPP protocol, subscribing to multiple contacts' presence information creates roster updates (e.g., contact list updates) that require a roster “push” to users (e.g., contacts' presence information changes are sent to users when updated). In addition, in an XMPP protocol, to remove a subscription requires sending an unsubscribe request (or cancellation of the subscription), which is likewise subject to individual processing and roster updates. Further, in both SIP and XMPP protocols, presence subscriptions update watcher information (e.g., information provided to a watcher, which is a component that monitors presence information), which requires additional processing related to watcher information management. Thus, these individual presence subscriptions and associated management of the subscriptions are costly in terms of CPU usage and network bandwidth.
The cost of individual presence subscriptions becomes even more apparent when considering a situation of medium or large scale deployment of presence systems. For example, consider the case of a large size business using a presence system. Some organizations may have 5,000-10,000 users. If any one percent of the users were to execute subscription requests, this would mean that there are fifty to one hundred simultaneous subscription requests occurring at one time. If there are ten percent of users executing subscription requests, this would generate five hundred to one thousand simultaneous subscription requests. Moreover, if a user desires to subscribe to ten of their contacts, ten corresponding individual subscriptions will be created. If the ten percent of users do this in an organization with 5,000 users, for example, 5,000 simultaneous subscriptions would be created requesting presence information. In the case of SIP, this means 5,000 SUBSCRIBE requests would be almost instantaneously sent out, and in the case of XMPP, 5,000 presence subscribe packets would be almost simultaneously sent out. If the size of the organization is doubled, this at least doubles the number of these requests.
Furthermore, if the above scenarios are considered in the context of a pattern of use that involves a user search facility (whereby the user search facility allows a user to search for any contact (or other user) in an organization, and the resulting set of users from the search is rendered in the client application with a corresponding presence indicator), then it is possible that at any one time this search facility could generate a significant number of individual presence requests to match the user search results. Thus, if each search returned an average of ten contacts, then this would correspond to an instantaneous submission of ten individual presence requests. For ten percent of 5,000 users, this will result in 500 instantaneous presence requests.
In addition, another problem with current presence systems occurs when the presence system is using certain ACL privacy policies. For example, CPU and bandwidth usage, along with customer satisfaction, may become problematic when a presence system is using an ACL privacy policy set to “CONFIRM.” In a CONFIRM privacy policy, each contact for which the user is requesting presence information is required to explicitly authorize and confirm their response to any presence subscription request. Such individual confirmations may be executed by a pop up window on the contact's terminal, or other method that solicits the contact's input regarding the presence subscription request. These individual confirmations add to the CPU usage and network bandwidth problems, and some contacts may find frequent pop ups annoying or unacceptable.
Also, a user may have a set of contacts where the contacts are “presence buddies.” Being presence buddies means that a long-term presence subscription is established between the user (e.g., watcher) and their contacts (e.g., presentities). However, a user may wish to communicate with other contacts (not presence buddies) on an intermittent basis, and may not have that contact listed on their contact list. Thus, users may use user search facilities to find the contacts; however a contact search will result in individual presence subscribe requests, which is also subject to privacy processing.